Method and system for multiple object representation

ABSTRACT

Methods, computer-readable media, and systems for multiple object representation in Java™ are provided. In some illustrative embodiments, a method for multiple object representation in Java software that executes on a processor is provided. The method includes creating a Java representation of a system level data structure, changing a field in the Java representation, and updating a corresponding field in the system level data structure using the contents of the field in the Java representation.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of European Patent Application No.04291918.3, filed Jul. 27, 2004, incorporated by reference herein as ifreproduced in full below. This application is related to co-pending andcommonly assigned applications Ser. No. ______ (Attorney Docket No.TI-38582 (1962-23300)), entitled, “Method And System For ManagingVirtual Memory,” and Ser. No. ______ (Attorney Docket No. TI-38593(1962-23400)), entitled “Method And System For Implementing InterruptService Routines,” which are incorporated by reference herein.

BACKGROUND OF THE INVENTION

Mobile electronic devices such as personal digital assistants (PDAs) anddigital cellular telephones are increasingly including applicationswritten in the Java™ programming language. Many of these mobile devicesinclude operating systems written in programming languages other thanJava. To increase system stability, it would be desirable to implementall or part of the operating system using the Java programming language.However, manipulating low-level system data structures such as pagetables, registers, interrupts, and task structures is difficult in Java.Such low-level structures typically are bit-based structures or complexstructures with field sizes that cannot be represented directly in Javastructures. For example, there is no way to create in Java a field offive bits that corresponds physically to only five bits in memory.Enhancements to improve the ability to manipulate low-level system datastructures in Java™ applications are desirable.

SUMMARY

Accordingly, there are disclosed herein methods, computer-readablemedia, and systems for multiple object representation in Java. Someembodiments provide a method for multiple object representation in Javasoftware that executes on a processor comprising creating a Javarepresentation of a system level data structure, changing a field in theJava representation, and updating a corresponding field in the systemlevel data structure using the contents of the field in the Javarepresentation.

Additional embodiments provide computer-readable media storing Javaprograms that, when executed by a processor, perform the above-describedmethods. Other embodiments provide systems that comprise a processor, aJava virtual machine configured to execute on the processor, and a Javasoftware program configured to execute on the Java virtual machine. TheJava software programs are configured to perform the above-describedmethods.

NOTATION AND NOMENCLATURE

Certain terms are used throughout the following description and claimsto refer to particular system components. As one skilled in the art willappreciate, semiconductor companies may refer to a component bydifferent names. This document does not intend to distinguish betweencomponents that differ in name but not function. In the followingdiscussion and in the claims, the terms “including” and “comprising” areused in an open-ended fashion, and thus should be interpreted to mean“including, but not limited to . . . ”. Also, the term “couple” or“couples” is intended to mean either an indirect or direct connection.Thus, if a first device couples to a second device, that connection maybe through a direct connection, or through an indirect connection viaother devices and connections.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more detailed description of the preferred embodiments of thepresent invention, reference will now be made to the accompanyingdrawings, wherein:

FIG. 1 shows a diagram of a system in accordance with embodiments of theinvention;

FIG. 2 shows a block diagram of the JSM of FIG. 1 in accordance withembodiments of the invention;

FIG. 3 illustrates multiple object representation in accordance withembodiments of the invention;

FIGS. 4, 6, and 8 show examples of using multiple object representationin accordance with embodiments of the invention;

FIGS. 5, 7A, 7B, and 9 show Java source code examples of methods inaccordance with embodiments of the invention; and

FIG. 10 depicts an illustrative embodiment of the system describedherein.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following discussion is directed to various embodiments of theinvention. Although one or more of these embodiments may be preferred,the embodiments disclosed should not be interpreted, or otherwise used,as limiting the scope of the disclosure, unless otherwise specified. Inaddition, one skilled in the art will understand that the followingdescription has broad application, and the discussion of any embodimentsis meant only to be exemplary of those embodiments, and not intended tointimate that the scope of the disclosure, is limited to thoseembodiments.

The subject matter disclosed herein is directed to methods that providemultiple object representation in Java and methods for using multipleobject representation. In embodiments of these methods, a Java class iscreated that provides both a Java representation and systemrepresentation of a system level data structure. The Java representationmay be manipulated in Java and the system representation may be updatedwith the results of these manipulations by a method defined in the Javaclass. Conversely, the system representation may be manipulated bynon-Java code (e.g., a device driver) and the Java representation may beupdated with the results of these manipulations by a method defined inthe Java class. Merely by way of example, the embodiments describedherein are directed to a Java Virtual Machine implemented on a Javaprocessor referred to herein as a Java Stack Machine. These embodimentsshould not be construed as limitations of the scope of this disclosure.The methods described are applicable to implementations of the JavaVirtual Machine on other processors including general purposeprocessors.

FIG. 1 shows a system 100 in accordance with embodiments of theinvention. As shown, the system may comprise at least two processors 102and 104. Processor 102 may be referred to for purposes of thisdisclosure as a Java Stack Machine (“JSM”) and processor 104 may bereferred to as a Main Processor Unit (“MPU”). System 100 may alsocomprise memory 106, and a display 114 coupled to both the JSM 102 andMPU 104 via one or more busses 122. At least a portion of the memory 106may be shared by both processors, and if desired, other portions of thememory 106 may be designated as private to one processor or the other.Other components such as disk drives and controllers (not specificallyshown) may be included as desired for various applications.

System 100 also comprises a Java Virtual Machine (“JVM”) 108, compiler110, Java APIs 120, Java native APIs 124, and Java applications 118. TheJVM may comprise a class loader, bytecode verifier, garbage collector,and a bytecode interpreter loop to interpret the bytecodes that are notexecuted on the JSM processor 102. The Java applications 118 are writtenin Java language source code and may comprise references to one or moreclasses of the Java Application Program Interfaces (“APIs”) 120 and theJava native APIs 124. The Java native APIs 124 comprises interfaces toclasses and methods implemented in other languages such as C++, C orassembler.

The Java source code is converted or compiled to a series of bytecodes112, with each individual one of the bytecodes referred to as an“opcode.” Bytecodes 112 are provided to the JVM 108, possibly compiledby compiler 110, and provided to the JSM 102 and/or MPU 104 forexecution. In some embodiments, the JSM 102 may execute at least someJava bytecodes directly. When appropriate, however, the JVM 108 may alsorequest the MPU 104 to execute one or more Java bytecodes not executedor executable by the JSM 102. In addition to executing compiled Javabytecodes, the MPU 104 also may execute non-Java instructions.

The system 100 may host an operating system (not specifically shown)which performs various functions such as virtual memory management, thesystem task management (i.e., a scheduler), and most or all other nativetasks running on the system, management of the display 114, andreceiving input from various devices 116. This operating system may bewritten in Java and may utilize the methods described herein forimplementing interrupt handlers, managing virtual memory, and/or forproviding a Java view of other system data structures (i.e., multipleobject representation). As is described in more detail herein,embodiments of the method for multiple object representation compriseproviding joint Java representation and system level representation of asystem data structure with appropriate methods for updating each of therepresentations.

Java bytecodes perform stack-based operations. For example, an “IADD”(integer add) Java opcode pops two integers off the top of the stack,adds them together, and pushes the sum back on the stack. A “simple”opcode is one in which the JSM 102 may perform an immediate operationeither in a single cycle (e.g., an IADD opcode) or in several cycles(e.g., “DUP2_X2”). A “complex” opcode is one in which several memoryaccesses may be required to be made within the JVM data structure forvarious verifications (e.g., NULL pointer, array boundaries).

A JSM processor 102 in accordance with embodiments of the invention mayexecute, in addition to the Java bytecodes, a second instruction setother than Java™ bytecodes. In some embodiments, the second instructionset may comprise register-based and memory-based operations rather thanstack-based operations. This second instruction set complements the Javainstruction set and, accordingly, may be referred to as a complementaryinstruction set architecture (“C-ISA”). By complementary, it is meantthat some complex Java bytecodes may be replaced by a “micro-sequence”comprising C-ISA instructions. The execution of Java code may thus bemade more efficient and run faster by replacing some opcodes with moreefficient micro-sequences of C-ISA instructions. For example, thecompiler 110 may scan a series of Java bytes codes and replace one ormore of such bytecodes with an optimized code segment mixing CISA andbytecodes and which is capable of more efficiently performing thefunction(s) performed by the initial group of Java bytecodes. In atleast this way, Java execution may be accelerated by the JSM 102.

The CISA instruction set comprises a plurality of instructions includinga “PACK” instruction and an “UNPACK” instruction. The PACK instructioncopies the contents of a source data field from the m lowest order bitsof a source register to a destination data field of size m in adestination register at a specified location in the destinationregister. The UNPACK instructions copies the contents of a source datafield of size m at a specified location in a source register to adestination register. The operation of the PACK and UNPACK instructionsis explained in more detail in co-pending U.S. patent application Ser.No. 11/116,918, entitled “Unpack Instruction” and co-pending U.S. patentapplication Ser. No. 11/116,897 entitled “Pack Instruction,” both ofwhich are incorporated herein by reference.

FIG. 2 shows an illustrative block diagram of the JSM 102. As shown, theJSM comprises a core 128 coupled to data storage 136 and instructionstorage 130. The components of the core 128 preferably comprise aplurality of registers 140, address generation units (“AGUs”) 142 and147, micro-translation lookaside buffers (micro-TLBs) 144 and 156, amulti-entry micro-stack 146, an arithmetic logic unit (“ALU”) 148, amultiplier 150, decode logic 152, and instruction fetch logic 154. Datapointed to by operands of opcodes may be retrieved from data storage 122or from the micro-stack 146, and processed by the ALU 148. Instructionsmay be fetched from instruction storage 130 by fetch logic 154 anddecoded by decode logic 152. The AGUs 142 may be used to calculateaddresses for C-ISA instructions based, at least in part, on datacontained in the registers 140. AGU 147 couples to the micro-stack 146and may manage overflow and underflow conditions in the micro-stack 146.The micro-TLBs 144 and 156 perform the function of a cache for theaddress translation and memory protection information bits that areunder the control of the operating system.

Java bytecodes may pop data from and push data onto the micro-stack 146,which micro-stack 146 comprises a plurality of gates in the core 128 ofthe JSM 102. The micro-stack 146 comprises the top n entries of a largerstack that is implemented in data storage 136. Although the value of nmay be vary in different embodiments, in accordance with at least someembodiments the size n of the micro-stack may be the top eight entriesin the larger, memory-based stack. By implementing the micro-stack 146hardware in the core 128 of the processor 102, access to the datacontained in the micro-stack 146 is very fast, although any particularaccess speed is not a limitation on this disclosure.

ALU 148 adds, subtracts, and shifts data. The multiplier 150 may be usedto multiply two values together in one or more cycles. The instructionfetch logic 154 fetches instructions from instruction storage 130, whichinstructions may be decoded by decode logic 152. Because the JSM 102 isconfigured to process instructions from at least two instruction sets,the decode logic 152 comprises at least two modes of operation, one modefor each instruction set. As such, the decode logic unit 152 maycomprise a Java mode in which Java bytecodes may be decoded, and a C-ISAmode in which micro-sequences of C-ISA instructions may be decoded.

The data storage 136 comprises data cache (“D-cache”) 138 and datarandom access memory (“D-RAM”) 139. The stack (excluding the micro-stack146), arrays and non-critical data may be stored in the D-cache 138,while Java local variables, critical data and non-Java variables (e.g.,C, C++) may be stored in D-RAM 139. The instruction storage 130 maycomprise instruction RAM (“I-RAM”) 132 and instruction cache (“I-CACHE”)134. The I-RAM 132 may be used for opcodes or micro-sequences, and theI-CACHE 134 may be used to store other types of Java bytecode and mixedJava/C-ISA instructions.

FIG. 3 illustrates a method for multiple object representation inaccordance with embodiments of the invention. In this method, a Javaclass is defined that comprises a Java representation of a system leveldata structure. Examples of such a Java class may be seen in FIGS. 5,7A, 7B, and 9 and are described in more detail below. In someembodiments, this Java class may comprise a constructor that invokes aJava native method to create the system level data structure. In otherembodiments, the system level data structure may be pre-defined. TheJava class definition may comprise one or both of two Java nativemethods for updating the system level data structure and/or the Javarepresentation. One of these Java native methods, referred to herein asUpdateSystemView, updates the system level data structure from thecontents of the Java representation. The other Java native method,referred to herein as UpdateJavaView, updates the Java representationfrom the contents of the system level data structure.

Using this class definition, an object 302 of the type represented bythe Java class may be instantiated in memory 106 by the operating systemor by one of the Java applications 118. In some embodiments, when theobject is instantiated, a constructor is invoked to create the systemlevel data structure 300 corresponding to the Java representation. Inother embodiments, the system level data structure 300 may bepre-existing. The operating system or application may use Javaoperations to change one or more fields in the Java representation ofthe system level data structure and then invoke the UpdateSystemViewmethod 306 to update the system level data structure 300. If thecontents of the system level data structure are changed, the operatingsystem or application may invoke the UpdateJavaView method 304 to updatethe Java representation 302.

In various embodiments, the Java representation comprises Java fieldsrepresenting each field of the system level data structure (e.g., theclass Segment of FIG. 5). Because Java fields are based on Javaprimitive types, the size of the Java field may be larger than the sizeof the corresponding field in the system level data structure. Forexample, if a field in the system level data structure is five bits insize, the Java field corresponding to this field may be defined as aJava type that corresponds to the byte size of the processorarchitecture (e.g., byte). If a field is 13 bits in size, thecorresponding Java instance variable may be defined as a Java type thatcorresponds to the word size of the processor architecture (e.g., int).

In such embodiments, the UpdateSystemView method copies only therelevant bits of the Java field to the corresponding field in the systemlevel data structure and the UpdateJavaView method copies the bits ofthe field in the system level data structure into the least significantbits of the corresponding Java field. In the latter case, sign extensionis performed for Java types byte, short, int, and long and zeroextension is performed for the Java type char. Embodiments of theUpdateSystemView method and the UpdateJavaView method may be implementedusing the Pack instruction or the Unpack instruction, respectively, ofthe JSM 102. In addition, in some embodiments, the UpdateSystemView andthe UpdateJavaView methods copy every field of the Java or systemrepresentation, respectively, to the corresponding field in the systemor Java representation, respectively. In other embodiments, theUpdateSystemView method and the UpdateJavaView methods only copy datafrom the fields which have changed in the Java or system representation,respectively.

In other embodiments of the multiple object representation method, theJava representation does not replicate fields of a system level datastructure. Instead, the Java representation may contain data that isused in conjunction with a system level data structure and may containdata that is used in conjunction with the system level data structure(e.g., the class InterruptTable of FIG. 9). In such embodiments, theUpdateSystemView method performs the operations required to make thedata accessible using the system level data structure (e.g., generatinga JVM code sequence that used the data and placing the address of thecode sequence in a field of the system level data structure).

Using the above described methods for multiple object representation, itis possible to represent any type of system level data structure inJava, thus making the implementation of operating system functions suchas virtual memory management and interrupt handling in Java easier.FIGS. 4-9 present examples of using multiple object representation forthe implementation of virtual memory management and interrupt handlingin accordance with embodiments of the invention. FIGS. 4 and 5illustrate the use of multiple object representation to implement anobject that represents a segment descriptor in a virtual memorymanagement system based on segmentation. FIGS. 6, 7A, and 7B illustratethe use of multiple object representation to implement the low-levelstructures used in a virtual memory management system based on paging.FIGS. 8 and 9 illustrate the use of multiple object representation toimplement interrupt service routines. FIGS. 5, 7A, 7B, and 9 presentexample Java code. The Java code is presented by way of example only.Other implementations are possible and fall within the scope of thisdisclosure.

A virtual memory management system allows processes to use a memoryaddress space that exceeds the size of the physical memory of thecomputer system. The virtual address space of a process is divided intoportions, i.e., segments or pages, and the operating system moves theseportions between physical memory and secondary storage as needed duringthe life of the process. At any point in time, portions of the virtualmemory space of multiple processes may occupy physical memory.

In general, a virtual memory management system is implemented with acombination of operating system software and hardware comprising atleast a memory management unit. When an executing process accesses amemory location, the address specified by the process, i.e., the virtualaddress, is passed to the MMU. The MMU uses one or more addresstranslation data structures (e.g., page tables, page table directories,page descriptors, and/or segment descriptors), explained in more detailbelow, to either translate the virtual address to a physical address orto determine that the data corresponding to the virtual address iscurrently not in physical memory. In the latter case, the MMU generatesa virtual memory exception to notify the operating system to handle thesituation.

The operating system is responsible for: (1) determining what portionsof the virtual memory space of a process are maintained in physicalmemory and what portions are placed in secondary storage; (2)maintaining the address translation data structures used by the MMU; and(3) handling virtual memory exceptions. Such handling includes freeingup or allocating space in physical memory to hold the missinginformation, possibly copying a portion of the virtual memory space ofanother process to secondary storage to make room for the missinginformation, bringing the relevant information in from secondarystorage, and updating the address translation data structures.

A virtual memory management system may be based on segmentation, pagingor some combination of the two. FIGS. 4 and 5 illustrate the use ofmultiple object representation to implement a Java class that representsa segment descriptor of a virtual memory management system based onsegmentation. In this type of virtual memory management system, thevirtual address space of each process is divided into blocks ofcontiguous memory called segments. In general, each segment has aparticular use. These segments may vary in size and a process may haveone or more segments. For example, a process may have a code segmentstoring executable code, a data segment holding the data used or createdby the code segment, a stack segment used exclusively for storing astack used by the process, and/or a heap segment used exclusively forheap storage by the process.

In a segmented virtual memory management system, a virtual address 400is comprised of a segment descriptor index 402 and a segment index 404.The relative sizes of the segment descriptor 402 and the segment index404 depend on the architecture of the memory management unit (“MMU”)managing memory 106. A segment descriptor index 402 identifies thesegment descriptor 408 in a segment table (not specifically shown) thatcorresponds to the memory segment 420 containing the physical address422 corresponding to the virtual address 400. The segment index 404contains the offset of that physical address 422 within the memorysegment 420.

A new segment descriptor is created by the operating system for eachsegment required by a process. The format of a segment descriptor mayvary depending on the architecture of the MMU. In some embodiments, thesegment descriptor 408 may be comprised of a base address field 412, asize field 414, and an access field 410. The base address 412 containsthe starting physical address of the memory segment 420. The size fieldcontains the size of the segment 420. The contents of the access field410 may vary depending on the architecture of the MMU. For example, theaccess field 410 may contain bits fields defining the access attributes(e.g., read, write, execute) of the segment 420. The access field 410may also contain bits for managing the swapping of the segment tosecondary storage (not specifically shown) such as a bit that is set ifthe segment is currently in memory 106 and a bit that is set if thesegment 420 is modified.

FIG. 5 presents an example of a Java class for creating and managing asegment descriptor 408 in Java using the previously described method formultiple object representation. A class Segment is defined thatcomprises a Java view of the segment descriptor (lines 3-5) and aconstructor that invokes a Java native method to create the systemrepresentation of the segment descriptor (lines 7-10) that is used bythe MMU. The class also comprises a native method UPDATESYSTEMVIEW (line12) that may be called to update the system representation of thesegment descriptor if the fields of the Java view are changed. Thisnative method contains the code required to copy the contents of theJava fields to the corresponding fields in the system representation.

In some embodiments, the operating system of system 100 may use theabove class for virtual memory management based on segmentation. Forexample, when the operating system allocates a segment 420 for aprocess, the operating system may instantiate a new segment object 406using the Segment class. A Java object 406 is allocated that containsthe Java representation of the segment descriptor 408. The constructoris executed to allocate the segment descriptor 408. The operating systemmay then use Java operations to initialize the access, size, and baseaddress fields of the Java representation 406 to correspond to the newsegment 420. Once these fields are initialized, the operating system maycall the UPDATESYSTEMVIEW method 416 to copy the values in the Javarepresentation 406 to the corresponding fields in the segment descriptor408. The MMU may then use the segment descriptor 408 for virtual addresstranslation.

The operating system may also cause the segment 420 to be swapped out ofphysical memory to secondary storage if the physical memory allocated tothe segment 420 is needed by another process. If the segment 420 isremoved from physical memory 106, the operating system may use Javaoperations to update the bit in the access field of the Java view thatindicates whether or not the segment is in memory and then callUPDATESYSTEMVIEW to update the segment descriptor 408. When the segment420 is again accessed by the process owning the segment, the MMU willsignal a segment exception to the operating system. The operating systemcauses the segment 420 to be swapped back into the physical memory 106but not necessarily at the same base address. When the segment 420 isplaced in physical memory 106 again, the operating system may use Javaoperations to update the bit in the access field of the Java view 408 toindicate that the segment 420 is in physical memory 106 and to updatethe base address field with the current physical address of the segment420. The operating system then calls UPDATESYSTEMVIEW to update thesegment descriptor 408.

FIGS. 6, 7A, and 7B illustrate the use of multiple object representationto implement the low-level structures used in a virtual memorymanagement system based on paging. In this type of virtual memorymanagement system, the virtual address space of each process is dividedinto equal sized blocks of contiguous memory called pages. In someembodiments, a virtual address 600 is comprised of a page directoryindex 602, a page table index 604 and a page index 606. The relativesizes of the page directory index 602, the page table index 604, and thepage index 606 depend on the architecture of the memory management unit(“MMU”) managing memory 106. The page directory index 602 identifies thepage table descriptor 610 in a page table directory 608 of a page table612. The page table index 604 identifies the page descriptor 614 in thepage table 612 that corresponds to the memory page 620. The page index606 contains the offset of the physical address 622 that corresponds tothe virtual address 600 within the memory page 620. The MMU translatesthe virtual address 600 to the physical address 622 using the entries inthe page table directory 608 and the page table 612 specified in thevirtual address 600.

FIGS. 7A and 7B present examples of Java classes for creating andmanaging page tables and page table directories in Java using thepreviously described method for multiple object representation. In theseexamples, a minimal number of fields are comprised in the system leveldata structures for page table descriptors and page descriptors forpurposes of illustration. As one of ordinary skill in the art wouldknow, these descriptors may vary in complexity. Representations of themore complex descriptors fall within the scope of this disclosure.

Referring first to FIG. 7B, a class PageDescriptor is defined (lines39-46). This class defines Java instance variables or fields torepresent each field of a system level representation of a pagedescriptor 614 (lines 40-45). In some embodiments, these fields comprisea base address field, a size field, an access field, a Boolean field forindicating whether the page is in memory, a Boolean field for indicatingif the page has been modified, and a protection field. The address fieldcontains the physical address of the page. The size field contains thesize of the page. The contents of the access field may vary depending onthe architecture of the MMU. For example, the access field may containbits fields defining the access attributes (e.g., read, write, execute)of the page. The protection field contains bits specifying theprotection level of the page.

A class PageTable is defined (lines 24-37) for use in creating pagetables (e.g., page table 612). This class defines a Java representationof a page table that contains a predefined number of entries of typePageDescriptor (line 28). That is, each entry of the Java representationof a page table is comprised of the fields defined in the classPageDescriptor (lines 39-46. The class also comprises a constructor thatcreates the system level representation of a page table 612 (lines31-33). In addition, the class comprises a native Java method,UPDATSYSTEMVIEW, for updating the system representation of the pagetable from the entries of the Java representation of the page table(line 35).

Referring now to FIG. 7A, a class PageTableDescriptor (lines 16-230) isdefined. This class defines Java instance variables or fields torepresent each field of a system level representation of a page tabledescriptor 610 (lines 18-22). In some embodiments, these fields comprisea size field, a protection field, a Boolean field indicating if the pagetable is in physical memory or not, a Boolean field indicating whetherthe page table has been modified, and a field containing an objectreference to a page table object. The size field contains the size ofthe page table. The protection field contains bits specifying theprotection level of the page table.

A class Directory is defined (lines 1-14) for use in creating page tabledirectories (e.g., page table directory 608). This class defines a Javarepresentation of a page table directory that contains a predefinednumber of entries of type PageTableDescriptor (lines 5-6). That is, eachentry of the Java representation of a page table directory is comprisedof the five fields defined in the class PageTableDescriptor (lines18-22). The class also comprises a constructor that creates the systemlevel representation of a page table directory 608 (lines 8-10). Inaddition, the class comprises a native Java method, UPDATSYSTEMVIEW, forupdating the system representation of the page table directory from theentries of the Java representation of the page table directory (line12).

In some embodiments, the operating system of system 100 may use theabove paging classes for virtual memory management. For example, whenthe operating system loads a process initially, it may use the classDirectory to instantiate a Java representation of a page table directoryand a system level representation of the page table directory for theprocess. The Java representation of the page table directory isallocated sufficient memory to hold a predetermined number (i.e.,DIRECTORY_NUMBER_ENTRIES) of page table descriptor entries and theconstructor is executed to allocate the system level representation ofthe page table directory 608. Each entry of the Java representation ofthe page table directory is of type PageTableDescriptor.

The operating system may also use the PageTable class to create one ormore Java representations of page tables for the process. Each Javarepresentation of a page table is allocated sufficient memory to hold apredetermined number (i.e., PAGETABLE_NUMBER_ENTRIES) of page descriptorentries and the constructor is executed to allocate the system levelrepresentation of the page table 612. Each entry of the Javarepresentation of the page table is of type PageDescriptor. Theoperating system may use Java operations to initialize the fields of theappropriate page table descriptors in the Java representation of thepage table directory as new page tables are allocated for the process.The operating system may invoke the UPDATESYSTEMVIEW method of the classDirectory to update the system level representation of the page tabledirectory with new page table descriptors.

The operating system may also use Java operations to initialize thefields of the appropriate page descriptors in the Java representation ofthe page tables as new pages are allocated for the process. Once thesefields are initialized, the operating system may invoke theUPDATESYSTEMVIEW method of the class PageTable to update the systemlevel representation of a page table with the new page descriptors.

The operating system may also cause a page 620 to be swapped out ofphysical memory 106 to secondary storage if the physical memoryallocated to the page 620 is needed by another process. If the page 620is removed from physical memory 106, the operating system may use Javaoperations to update the inMemory field of the Java representation ofthe page descriptor and then call the UPDATESYSTEMVIEW method of theclass PageTable to update the system level representation of the pagedescriptor 614. When the page 620 is again accessed by the processowning the segment, the MMU will signal a segment exception to theoperating system. The operating system causes the page 620 to be swappedback into the physical memory 106 but not necessarily at the same baseaddress. When the page 620 is placed in physical memory 106 again, theoperating system may use Java operations to update the inMemory field ofthe Java representation of the page descriptor to indicate that the page620 is in physical memory 106 and to update the address field with thecurrent physical address of the page 620. The operating system may thencall UPDATESYSTEMVIEW to update the system level representation of thepage descriptor 614. The operating system may manage the swapping ofpage tables similarly.

FIGS. 8 and 9 illustrate the use of multiple object representation toimplement interrupt service routines for the system 100. The MPU 104 andJSM 102 may initiate a software routine in response to an asynchronouselectronic event, e.g., a signal from a device 116. This event, referredto as an interrupt, is signaled to the operating system via an interruptrequest (“IRQ”) 804. The operating system executes special interruptcode 806 to save the current context, to process an interrupt serviceroutine, i.e., interrupt handler, which handles the interrupt, and torestore the saved context. The address of this handler, i.e., theinterrupt vector, is generally stored in memory 106 in a table ofinterrupt vectors 802. This special interrupt code 806 comprises aninstruction sequence such as a JVM 108 opcode sequence as illustrated, aC-ISA instruction sequence, a native code instruction sequence, and/orinstructions of a non-Java virtual machine (e.g., a .net virtual machinethat defines its own instruction set).

FIG. 9 presents examples of Java classes that may be used by theoperating system to create the entries in the interrupt vector table802. A class InterruptTable is defined (lines 18-28). This class definesa Java representation of the interrupt vector table 800 as an array witha predetermined number of entries corresponding to the system levelrepresentation of the interrupt vector table 802. A method,insertmeonlevel, is comprised in the class (lines 22-25). This method isused to add Java interrupt handlers to the Java representation of theinterrupt vector table 800. The class also comprises a Java nativemethod, UPDATESYSTEMVIEW, for creating entries in the system levelrepresentation of the interrupt vector table 802 that access the Javainterrupt handlers (line 27). The operation of insertmeonlevel andUPDATESYSTEMVIEW are explained in more detail below.

An abstract class lnterruptHandler is also defined (lines 13-16). Thisclass comprises an abstract method Handler (line 15). Each Javainterrupt handler is defined as an extension of this class and mustimplement a method with the name Handler. In addition, each entry of theJava representation of the interrupt vector table 800 is a reference toan object of type InterruptHandler.

The class MyHandler is an example level 2 interrupt handler definition(lines 1-11). This class extends the class InterruptHandler (line 1) andcomprises the required definition of the method Handler (lines 3-5).While not specifically shown here, the Handler method contains Java codeto be executed when a level 2 interrupt is signaled. The class comprisesa method MyHandler that is used to after an object of type MyHandler isinstantiated to insert a reference to the object in the Javarepresentation of the interrupt vector table 800 at an entrycorresponding to the interrupt level of the handler (lines 7-10). TheMyHandler method invokes the insertmeonlevel method of InterruptTableclass to perform the insertion. In this example, the handler object isdefined to handle a level 2 interrupt so it will be inserted at entrytwo 808 in the Java representation of the interrupt vector table 800.

The operating system uses the class InterruptTable to instantiate anInterruptTable object. This InterruptTable object contains the Javarepresentation of the interrupt vector table 800. To create an interruptvector in the system level representation of the interrupt vector table802, the operating system uses the class MyHandler to instantiate ahandler object and invokes the MyHandler method to insert a reference tothe handler object in the Java representation of the interrupt vectortable 800 at the entry corresponding to interrupt level 2 808. Theoperating system then invokes UPDATESYSTEMVIEW to create an interruptvector in the system level interrupt vector table 802 at the entrycorresponding to interrupt level 2 810. UPDATESYSTEMVIEW generates a JVM108 opcode sequence 806, Jvm_handler, that invokes the Handler method ofthe MyHandler object and stores a reference to the Jvm_handler in thesystem level interrupt vector table 802 at the entry corresponding tointerrupt level 2 810. Then, when a level two interrupt 804 is signaledin system 100, the interrupt vector corresponding to the interrupt leveltwo 810 in the system level interrupt table 802 is selected. TheJvm_handler 806 is executed, which invokes the Java handler Handler ofthe MyHandler object to actually handle the interrupt.

The system 100 may be implemented as a mobile device 1015 such as thatshown in FIG. 10. As shown, the mobile device 1015 comprises anintegrated keypad 1012 and display 1014. The JSM processor 102 and MPUprocessor 104 and other components may be comprised in electronicspackage 1010 connected to the keypad 1012, display 1014, and radiofrequency (“RF”) circuitry 1016. The RF circuitry 1016 may be connectedto an antenna 1018.

While the various embodiments of the invention have been shown anddescribed, modifications thereof can be made by one skilled in the artwithout departing from the spirit and teachings of the invention. Theembodiments described herein are illustrative only, and are not intendedto be limiting. Many variations and modifications of the inventiondisclosed herein are possible and are within the scope of the invention.Accordingly, the scope of protection is not limited by the descriptionset out above. Each and every claim is incorporated into thespecification as an embodiment of the present invention.

1. A method for multiple object representation in Java software thatexecutes on a processor, comprising: creating a Java representation of asystem level data structure; changing a field in the Javarepresentation; and updating a corresponding field in the system leveldata structure using the contents of the field in the Javarepresentation.
 2. The method of claim 1, wherein creating a Javarepresentation further comprises: instantiating a Java object using aJava class representing the system level data structure, wherein theJava class comprises a Java native method for updating the system leveldata structure; and updating a corresponding field in the system leveldata structure further comprises executing the Java native method. 3.The method of claim 2, wherein the field in the Java representation islarger than the corresponding field in the system level data structure,and executing a Java native method further comprises copying therelevant bits from the field in the Java representation to thecorresponding field in the system level data structure.
 4. The method ofclaim 3, wherein the Java native method uses a pack instruction of theprocessor.
 5. The method of claim 2, wherein the Java class comprises aconstructor to create the system level data structure, and instantiatingthe Java object further comprises executing the constructor, wherein thesystem level data structure is created.
 6. The method of claim 1,further comprising: changing a field in the system level data structure;and updating a corresponding field in the Java representation using thecontents of the field in the system level data structure.
 7. The methodof claim 6, wherein creating a Java representation further comprises:instantiating a Java object using a Java class representing the systemlevel data structure, wherein the Java class comprises a Java nativemethod for updating the Java representation; and updating thecorresponding field in the Java representation further comprisesexecuting the Java native method.
 8. The method of claim 7, wherein thefield in the system level data structure is smaller than thecorresponding field in the Java representation, and executing a Javanative method further comprises copying the field in the system leveldata structure to the least significant bits of the corresponding fieldin the Java representation.
 9. The method of claim 8, wherein the Javanative method uses an unpack instruction of the processor.
 10. Acomputer-readable medium storing a Java program that, when executed by aprocessor, performs a method comprising: creating a Java representationof a system level data structure; changing a field in the Javarepresentation; and updating a corresponding field in the system leveldata structure using the contents of the field in the Javarepresentation.
 11. The computer readable medium of claim 10, whereincreating a Java representation further comprises: instantiating a Javaobject using a Java class representing the system level data structure,wherein the Java class comprises a Java native method for updating thesystem level data structure; and updating a corresponding field in thesystem level data structure further comprises executing the Java nativemethod.
 12. The computer readable medium of claim 11, wherein the fieldin the Java representation is larger than the corresponding field in thesystem level data structure, and executing a Java native method furthercomprises copying the relevant bits from the field in the Javarepresentation to the corresponding field in the system level datastructure.
 13. The computer readable medium of claim 12, wherein theJava native method uses a pack instruction of the processor.
 14. Thecomputer readable medium of claim 11, wherein the Java class comprises aconstructor to create the system level data structure, and instantiatingthe Java object further comprises executing the constructor, wherein thesystem level data structure is created.
 15. The computer readable mediumof claim 10, further comprising: changing a field in the system leveldata structure; and updating a corresponding field in the Javarepresentation using the contents of the field in the system level datastructure.
 16. The computer readable medium of claim 15, whereincreating a Java representation further comprises: instantiating a Javaobject using a Java class representing the system level data structure,wherein the Java class comprises a Java native method for updating theJava representation; and updating the corresponding field in the Javarepresentation further comprises executing the Java native method. 17.The computer readable medium of claim 16, wherein the field in thesystem level data structure is smaller than the corresponding field inthe Java representation, and executing a Java native method furthercomprises copying the field in the system level data structure to theleast significant bits of the corresponding field in the Javarepresentation.
 18. The computer readable medium of claim 17, whereinthe Java native method uses an unpack instruction of the processor. 19.A system, comprising: a processor; a Java virtual machine (“JVM”)configured to execute on the processor; and a Java software programconfigured to execute on the JVM, wherein the Java software program isconfigured to create a Java representation of a system level datastructure, to change a field in the Java representation, and to update acorresponding field in the system level data structure using thecontents of the field in the Java representation.
 20. The system ofclaim 19, wherein the Java software program is further configured toinstantiate a Java object using a Java class representing the systemlevel data structure, wherein the Java class comprises a Java nativemethod for updating the system level data structure; and to update acorresponding field in the system level data structure by executing theJava native method.
 21. The system of claim 19, wherein the field in theJava representation is larger than the corresponding field in the systemlevel data structure, and executing the Java native method furthercomprises copying the relevant bits from the field in the Javarepresentation to the corresponding field in the system level datastructure.
 22. The system of claim 21, wherein the Java native methoduses a pack instruction of the processor.
 23. The system of claim 20,wherein the Java class comprises a constructor to create the systemlevel data structure, and the Java software program is furtherconfigured to execute the constructor, wherein the system level datastructure is created.
 24. The system of claim 19, wherein the Javasoftware program is further configured to change a field in the systemlevel data structure, and to update a corresponding field in the Javarepresentation using the contents of the field in the system level datastructure.
 25. The system of claim 24, wherein the Java software programis further configured to instantiate a Java object using a Java classrepresenting the system level data structure, wherein the Java classcomprises a Java native method for updating the Java representation; andto update the corresponding field in the Java representation byexecuting the Java native method.
 26. The system of claim 25, whereinthe field in the system level data structure is smaller than thecorresponding field in the Java representation, and executing the Javanative method further comprises copying the field in the system leveldata structure to the least significant bits of the corresponding fieldin the Java representation.
 27. The system of claim 26, wherein the Javanative method uses an unpack instruction of the processor.
 28. Thesystem of claim 19, wherein the system comprises a mobile device.